Repository navigation
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
the enableJSONOnly check in HTTPTransportUtils.isJSONRequest now compares only the media type, the part before any parameters, with application/json (case-insensitively) instead of searching the whole Content-Type header for it. it is the gate in AxisServlet.doPost and in both processHTTPPostRequest overloads (servlet and standalone HTTPWorker), while the builder is chosen from the media type, so "application/x-www-form-urlencoded; x=application/json" passed the gate and was handled as a form post: AxisServlet.doPost sends it to RESTUtil.processXMLRequest, which does not repeat the check (one that called isJSONRequest would pass it too), XFormURLEncodedBuilder binds it, the operation is dispatched by request URI, and JsonRpcMessageReceiver's RPCMessageReceiver fallback invokes it and answers in XML. text/plain, text/xml and application/xml with the same parameter get their XML body parsed the same way. whether a Content-Type is CORS-safelisted is decided from its essence alone, so the form-urlencoded and text/plain variants go cross-site without a preflight, which is what a mandatory application/json is there to prevent for cookie-authenticated services (CWE-352). with the spring-boot-starter's axis2-json.xml behind the real AxisServlet in Jetty, such a POST to a zero-argument operation returned 200 and ran it, while the same POST without the parameter got 400; after the change both get the JSON-only 400, and application/json, application/json; charset=UTF-8 and Application/JSON still reach the operation. a type that merely contains application/json, such as application/json-patch+json or application/json with a space before the ';', is now refused at the gate; no builder matched those, so they were already parsed as XML and failed with a 500. AxisServletJSONOnlyTest gains a doPost case that fails before the change (the operation is reached) and a unit check of isJSONRequest; transport-http (116 tests), json (163), openapi (272), spring-boot-starter (19) and transport-h2 (84) verify with -Papache-release.